An error one might encounter with Azure AD SSO

#1

One might encounter the following error:

AADSTS750: Authentication method “WindowsIntegrated, MultiFactor” by which the user authenticated with the service doesn’t match requested authentication method “Password, ProtectedTransport”

Our Azure SSO Integration Guide (under FAQ) has an in-depth technical description of why this occurs. Understanding the underlying mechanics of this, so that we could come up with an adequate explanation, took some reading into the SAML 2.0 Protocol Core Specification as well as the Azure SAML Protocol documentation. However, I must confess, when I went back to read what I had helped write way back then, it actually took me a few read-throughs to understand the underlying meaning.

So, this time around, I thought I’d have a bit of fun coming up with a more illustrative description of how it all happens. For the layperson, it may help to imagine the following brief dialogue that transpires, which leads to the error message:

User: “I want to sign in. Take me to my identity provider (IDP).”
PD (to user): “Okay, take this note (authentication request) to your IDP, which is over this way.”
PD (note to IDP reads): “This person wants to sign in to me. Their authentication method must EXACTLY match the minimum one that I typically require - and this exactness is as you have demanded that I require of users. The minimum that I ask is that the identity provider make their users provide a password (one authentication factor) per what I say here in my RequestedAuthnContext element.”
User’s web browser: “Here’s an authentication request. I have WindowsIntegrated and want to use that to authenticate.”
AD: (reads note) “Okay user, you say want to sign in using WindowsIntegrated? TOO BAD, THAT METHOD IS NOT ALLOWED! IT MUST BE A PASSWORD AND ONLY A PASSWORD.”
PD (aside): But wait a minute AD, you yourself don’t even support WindowsIntegrated when specifying a RequestedAuthnContext element per your documentation*! The only way I could get around this is by the footgun of not requesting a minimum of authentication requirements, thus permitting disastrously insecure SAML configurations wherein no authentication method is required by the identity provider!

* Per the FAQ:

  • PagerDuty includes the RequestedAuthnContext element to request that the identity provider use, at the bare minimum, password authentication to identify users.
  • Azure expects the service provider require an exact match between the authentication type provided with the one requested, whenever RequestedAuthnContext is provided.
  • Azure only supports requesting Password type authentication when specifying RequestedAuthnContext.

Users can get around this issue by using a different web browser that does not attempt to authenticate with the identity provider via the WindowsIntegrated authentication method, and using password authentication to access their identity.

1 Like
#2

Addendum: Microsoft has since the original writing of the FAQ updated the documentation on Azure AD SSO’s handling of the RequestedAuthnContext element to now read:

Azure AD supports AuthnContextClassRef values such as urn:oasis:names:tc:SAML:2.0:ac:classes:Password .

Whereas it originally read:

Azure AD supports only one AuthnContextClassRef value: urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

While this does not necessarily imply that it supports WindowsIntegrated, it does raise the question. If it is supported, I wondered, would be possible to construct AuthnContext to allow this authentication method?

If it were possible to specify a list of authentication context classes and still have it work with both the minimum and exact comparison, then the WindowsIntegrated method could probably be added to the list of minimum required authentication contexts.

Lines 1867-1876 of the core SAML spec imply that more than one class reference can be given, as the first will be treated with precedence (the one that matches first is used).

Lines 1883-1884 make sense in light of this straightforward interpretation and confirm the logic is to select one of any that match (if the comparison is set to “exact”):

1883 If Comparison is set to “exact” or omitted, then the resulting authentication context in the authentication
1884 statement MUST be the exact match of at least one of the authentication contexts specified.

Let us know if you are interested and we can investigate this possibility further!

#3

Update:

We have a workaround for this (omitting RequestedAuthnContext) that we can confirm works, and can enable it in PagerDuty accounts per request. Please contact support if your users are encountering this error and you would like to try this solution in the mean time.

We will be discussing this further to find the most elegant solution.

1 Like
#4

The only way I could get around this is by the footgun of not requesting a minimum of authentication requirements, thus permitting disastrously insecure SAML configurations wherein no authentication method is required by the identity provider!

Just wondered if this is really insecure? If you don’t specify an authentication method, surely this just means that any method, whether it’s password, x509 cert, Windows auth is valid? The Microsoft docs say it is an optional element: https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol#requestauthncontext

1 Like
#5

So did this ever go anywhere on the PagerDuty side? We’re getting this same problem, but obviously don’t want to introduce anything “disastrously insecure”. As I read this though it sounds like as long as on the SAML side you only provide secure mechanisms as options, then disabling the ‘EXACT’ setting on the PD side shouldn’t be any extra insecure.